home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000163_ahn@cbnmva.att.com _Tue Jul 6 17:05:48 1993.msg < prev    next >
Internet Message Format  |  1996-01-31  |  3KB
  1. Received: from univers.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP
  2.     id AA13145; Tue, 6 Jul 1993 21:10:33 MST
  3. Message-Id: <199307070410.AA06086@univers.cs.arizona.edu>
  4. Received: from att.UUCP by univers.cs.arizona.edu; Tue, 6 Jul 1993 21:10:30 MST
  5. Subject: Re: SQL temporal language extensions
  6. To: tsql@cs.arizona.edu
  7. Date: Tue, 6 Jul 93 17:05:48 EDT
  8. From: I. Ahn <ahn@cbnmva.att.com>
  9. X-Mailer: ELM [version 2.2 PL14]
  10.  
  11. Greetings.
  12. Please ignore it if you received this earlier.
  13.  
  14. I have some comments about the following constraints.
  15.  
  16.     > * Initially, the language design will support user-defined time and
  17.     >     valid time. Support for transaction time may be added later.
  18.                             ====================
  19. The need for supporting transaction time is important, as numerous people
  20. have commented in the workshop.
  21. I believe support of transaction time will be a major contribution of the
  22. "TSQL2 working group" in contrast with the approach of the
  23. "SQL2/3 working group", and will serve as the basis for the
  24. "TSQL3 working group" too.
  25.  
  26. I hope we can include this support from the beginning.
  27. Since the semantics of transaction time is relatively simple, it may not
  28. be difficult to agree upon a standard.
  29.  
  30. At least one commercial DBMS already supports the concept of transaction
  31. time to some degree.
  32. Sybase has the "timestamp" data type which is automatically updated
  33. whenever a row containing a timestamp column is inserted or updated.
  34. A restriction is that a table may have only one timestamp column.
  35.  
  36. What can happen is that other DBMS vendors may try to match or exceed
  37. this feature in differing ways, and then the standard has to catch up
  38. with the practices later on as it did for the user-defined time.
  39.  
  40.     > * Discrete time will be assumed.
  41.  
  42. I hope we can discuss this further.
  43. To assume discrete time, the standard has to specify the granularity of time.
  44. Some of the problems with this approach are:
  45.   - Time is inherently continuous, as the real number is.
  46.     Enough said about this in the workshop.
  47.   - Granularity is an issue of representation.
  48.   - It is not consistent with the "time" data type already defined
  49.     for the user-defined time in the SQL2 standard.
  50.     The standard says that the granularity is determined by each
  51.     implementation, not by the standard, except that at least
  52.     6 fractional digits should be supported.
  53.     I am not sure we want to invent a new representation of time
  54.     in addition to the above.
  55.  
  56.     In fact, SQL2 goes further and follows the convention of
  57.     the [closed, open) time.
  58.     e.g. the predicate
  59.         (time '10:00:00', time '12:00:00) overlaps
  60.         (time '11:00:00', time '13:00:00)    is true
  61.     but
  62.         (time '10:00:00', time '11:00:00) overlaps
  63.         (time '11:00:00', time '13:00:00)    is false.
  64.         
  65.     I believe this is a good convention, and we need good reasons and
  66.     a lot of efforts to change this.
  67.  
  68. Besides, we need to address not only the query statement, but also
  69. the data definition and data manipulation statements such as
  70. "create", "insert", "delete", and "update".
  71. The query statement alone will not be very useful, if there is no
  72. support for the other statements.
  73. I think any proposal should be evaluated in terms of how it deals
  74. or can deal with all these requirements as a whole.
  75.  
  76. Regards,
  77. Ilsoo Ahn (ahn@cbnmva.att.com)